For transmission of data having real-time characteristic such as video signal through a communication network including ethernet, it is generally performed to install a board for video signal processing (video card) and a network interface card into a PCI (Peripheral Components Interconnect) bus of personal computer and to transmit packets according to the network protocol such as Internet Protocol (hereinafter referred to as “IP”), User Datagram Protocol (hereinafter referred to as “UDP”) or Transmission Control Protocol (hereinafter referred to as “TCP”).
FIG. 11 is a block diagram of a prior art transmission system in which video signals are transmitted through ethernet. FIG. 11 shows an ethernet network interface card (hereinafter referred to as “NIC”) 500, a video card 501, a PCI bus 502, a CPU 503 and a memory 504.
The NIC 500 has a PCI interface part (hereinafter referred as to “PCI I/F part”) 520, an ethernet processing part 521 and a physical layer processing part 522. The video card 501 has a video signal processing part 510 and a PCI I/F part 511.
An input video signal is processed (for example, compressed) in the video signal processing part 510 and stored in the memory 504 through the PCI I/F part 511 and the PCI bus 502. The transmission on the PCI bus 502 is performed by the interruption of the video card 501 to the CPU 503 for DMA (Direct Memory Access) transfer.
Then, for stream transmission, the video data stored in the main memory 504 is separated every predetermined length by software processing in the CPU 503 (each separated video data is hereinafter referred to as a “video payload”), and each video payload is assigned a number for identification and then written into the main memory 504 again (it is hereinafter referred to as a “video packet”).
The CPU 503 reads out the video packet from the memory 504, performs UDP/IP processing and ethernet frame processing and writes the generated ethernet frame into the memory 504 again by software processing. Generally, for stream transmission, UDP is used for processing in the fourth layer of an OSI model and IP is used for processing in the third layer of the OSI model (the fourth layer and the third layer are hereinafter referred to as “UDP/IP”, collectively). The ethernet frame, that is subject to UDP/IP protocol processing and ethernet frame processing of the second layer, is stored in the memory 504.
The OSI model has a seven layer architecture consisting of the first layer as a physical layer, the second layer as a data link layer, the third layer as a network layer, the fourth layer as a transport layer, the fifth layer as a session layer, the sixth layer as a presentation layer and the seventh layer as an application layer.
Next, the CPU 503 notifies the NIC 500 that there is an ethernet frame to be transmitted in the memory 504. The NIC 500 interrupts the CPU 503 and captures the ethernet frame via the PCI bus 502 by DMA transfer of the PCI interface 520. The ethernet processing part 521 performs additional processing of the ethernet frame and sends the ethernet frame to the physical processing part 522. The ethernet frame in the final form is transmitted on ethernet.
At the time of receipt, when the NIC 500 receives an ethernet frame via the physical layer processing part 522 and the ethernet processing part 521, it interrupts the CPU 503 and writes the received ethernet frame into the memory 504 via the PCI bus 502 by DMA transfer of the PCI interface 520. Next, the CPU 503 reads out the ethernet frame from the memory 504, performs ethernet frame processing and UDP/IP processing, detects the number assigned to the video payload for identification at the time of transmission to assure ordinality and, after that, stores the generated video packet in the memory 504 again by software processing.
Next, the CPU 503 notifies the video card 501 that there is a stored video packet. The PCI interface 511 of the video card 501 interrupts the CPU 503 and captures the video packet via the PCI bus by DMA transfer. The video card 501 extracts video data and then performs processing such as expansion to output video.
The above-mentioned example is that of stream transmission of UDP/IP. File transfer by TCP/IP requires similar software processing. In the case of TCP/IP, flow control processing of TCP in addition to the above-mentioned processing is performed by software.
As mentioned above, protocol processing relating to transfer, part of processing such as video transmission and interrupt handling for memory copy and PCI bus transfer depend on software. The conventional example by performing the above-mentioned software processing is hereinafter referred to as a first conventional example.
As another conventional example, there is a technique disclosed in Unexamined Patent Publication No. 2000-59643 (hereinafter referred to as a second conventional example).
In the second conventional example, a dedicated processing means for generating real-time data packets (protocol dedicated processing means 26 in FIG. 2 of the second conventional example) is provided and in transmitting a large volume of contiguous real-time data such as moving pictures, high-speed transmission can be achieved. Moreover, in the second conventional example, a function of limiting transmission rate of real-time data (rate control means 23 in FIG. 2 of the second conventional example) is also provided.
Another conventional example is IEEE 1394 (hereinafter referred to as a third conventional example). In the third conventional example, transmission time is divided into a time zone during which isochronous data is transmitted (hereinafter referred to as an “isochronous zone”) and a time zone during which non-isochronous data is transmitted (hereinafter referred to as an “non-isochronous zone”). Data requiring real-time characteristic such as video (hereinafter referred to as “real-time data”) is transferred in the isochronous zone. Ordinary data for control or setting of equipment requiring no real-time characteristic is transferred in the non-isochronous zone. This enables transfer of real-time data and ordinary data.
As another conventional example, there is a technique disclosed in Unexamined Patent Publication No. 2002-185942 (hereinafter referred to as a fourth conventional example). The fourth conventional example relates to only transmission terminal (server) of video data.
The first feature of the fourth conventional example is that display interval of the video frame is used as a reference of transmitting the video data packet. However, the conventional example fails to specifically disclose how to perform control by utilizing the frame display interval.
The second feature is to transmit the TCI/IP packet only when the UDP/IP packet formed of video data is not transmitted. In addition, the conventional example discloses that the UDP/IP packet is processed by hardware and the TCI/IP packet is processed by software.
However, the above-mentioned conventional configuration has the following problems.
In the first conventional example, all of the ethernet frame processing and protocol processing of IP and UDP are performed by the CPU and further part of video signal processing is also performed by the CPU. For that reason, there is a problem that processing cannot keep up with tasks for stream transmission at high-bit rate. Moreover, as the PCI bus is used as a common bus, real-time data with higher priority to be transmitted or received and data with lower priority exist together, thereby causing a problem that real-time processing is too late.
These problems result from the following two reasons. Firstly, as data rate for stream transmission of video data is essentially very high, the CPU can exceed its performance limit. In transmitting the ethernet frame and the video packet on the PCI bus, the method called as multi-thread (multi-process) in terms of software, in which multiple transactions are performed concurrently in appearance, is adopted. In fact, these transactions are performed by time-sharing of the CPU. Secondly, due to overhead at the switching of thread (or referred to as task or process), CPU performance is lowered substantially, and due to memory copy repeated many times at processing, CPU throughput allocated to video transmission is limited.
The above-mentioned switching of thread depends on software of the operating system (hereinafter referred to as “OS”) and users cannot control processing completely.
Specifically, in the first conventional example, there causes a problem that the speed at which the CPU generates the ethernet frame cannot keep up with the data rate of the data to be transmitted (video data in this example) at transmission of the NIC and therefore the untransmitted video packet occurs, resulting in broken video image. Further, there is another problem that even when the ethernet frame can be generated at required data rate, transfer of the ethernet frame from the memory to the NIC cannot be completed in time.
Further, there is another problem that so-called shaping processing in which the video packet need to be transmitted at regular timings depends on the CPU (depends on software with variation in processing timing), so that accurate shaping cannot be achieved.
Furthermore, as decision on transmission proportion between high-priority data such as video signal and low-priority data such as management information also depends on the CPU (depends on software), the high-priority data is not necessarily transmitted by priority.
Moreover, at the time of receipt of the NIC, there is a possibility that the CPU cannot carry out switching to the thread for processing the receive frame and capture the incoming ethernet frame into the memory in time, thereby missing data in the NIC (abandonment of ethernet frame). Alternatively, even when the ethernet frame can be taken into the memory, the CPU can take too long for protocol processing, thereby failing to transmit data in real time.
Moreover, as another problem, since task management depends on the OS, a high priority is not necessarily given to processing of the high-priority data such as video signal over the low-priority data such as management information.
Use of high-performance CPU can increase its throughput, but it is not a fundamental solution to these problems. In addition, the high-performance CPU consumes a large volume of electric power. In the case of insufficient heat radiation especially in equipment with built-in CPU, the equipment can proper improper operations. The high-performance CPU also has a problem of being expensive.
These problems are aggravated in the case where the CPU performs processing of additional information such as management information in addition to transmission of video data.
The problems on network processing of the above-mentioned problems relating to the CPU essentially arise from the fact that network processing in the general operating systems is performed in sub-layers of the OSI architecture model in a sequential order.
The processing will be described specifically by taking the OSI model (seven layer architecture) that uses the physical layer as the first layer, ethernet as the second layer, internet protocol (IP) as the third layer and UDP as the fourth layer, as an example. At the receive terminal of ethernet, the physical layer as the first layer receives an ethernet frame and performs termination processing. Next, ethernet (second layer) performs termination processing of the ethernet frame, extracts an IP packet and sends it to the internet protocol (third layer). The internet protocol (third layer) processes the IP packet, extracts a UDP packet and sends it the fourth layer. In the fourth layer, termination processing of the UDP packet is performed.
Such processing in the order of layers causes processing overhead, imposing a burden on the CPU (software processing).
The above-mentioned problems occur at the transmission side of ethernet.
In the second conventional example, burden on the processor is reduced by generating the real-time data packet by use of the dedicated processing means. However, it discloses no method of controlling the generated real-time data packet and other packet generated in the processor. In the case of controlling these packets in the conventional method, the following problems arise.
The first problem is that the real-time data packet is not necessarily transmitted by priority. Specifically, in the case where a large number of non-real time data packets are generated in the second conventional example, transmission of the real-time data packets is limited, resulting in that real-time characteristic cannot be ensured.
As the second problem, it cannot be ensured that non-real time data is transmitted without system failure while giving a priority to transmission of real-time data. Non-real time data includes ARP (Address Resolution Protocol) data described as follows, SNMP (Simple Network Management Protocol) data for system management and data for confirming conduction between applications. With respect to the second problem, in the second conventional example, bit rate of real-time data can be lowered by the rate control means 23 in FIG. 2. In the second conventional example, however, no method of controlling transmission of real-time data and other data is disclosed. In other words, the second conventional example has a problem that quality of real-time data must be lowered to ensure transmission of the other data.
The second conventional example has the following third problem. In the case where transmission is performed on ethernet by using internet protocol (IP), ARP processing in which MAC (Media Access Control) address of the ethernet to be transmitted is acquired based on the IP address of destination is carried out. As ARP processing is performed through two-way communication, it is suitable to use a processor. However, in the second conventional example, there is no method of notifying results of ARP processing from the protocol general-purpose processing means 25 to the parameter setting means 29 in FIG. 2 and finally setting the MAC address in the header generating means 262. Therefore, the second conventional example has a problem that real-time data can be transmitted only to the fixed address hold by the parameter setting means 29 in advance. For that reason, there also causes another problem that port number cannot be set flexibly, for example, in the case of negotiating the port number of upper UDP protocol, not limited to ARP processing.
In the third conventional example, transmission zone of real-time data is previously determined according to time allocation. Therefore, in the case where the amount of real-time data to be transmitted in the isochronous zone is smaller and the amount of ordinary data to be transmitted is larger than the respective allocated transfer capability, the transmission zone is wasted. Similar problem also arises in the case where the amount of ordinary data to be transmitted in the non-isochronous zone is smaller and the amount of real-time data to be transmitted in the isochronous zone is larger than the respective allocated transfer capability. That is, the third conventional example has a problem that the proportion between real-time data and ordinary data cannot be changed flexibly.
The third conventional example has another problem that when real-time data to be transmitted generates during the time allocated to the non-isochronous zone, data transmission has to be postponed until the next isochronous zone, causing delay in transmission. Many applications are affected seriously by the delay of real-time data. As these applications require transmission of real-time data with short delay, it is a major problem. This delay problem occurs in transmission of ordinary data in the same way. When ordinary data to be transferred generates in the isochronous zone, data transmission has to be postponed until the next non-isochronous zone, causing a similar delay problem.
In the fourth conventional example, display interval of the video frame is used as a transmission reference of the video data packet. In this case, however, when the time necessary for processing of the video data exceeds the time interval of the video frame even if only slightly, the problem such as loss of real-time characteristic occurs, thereby causing break in image. Therefore, using the video frame as reference means control based on the extreme broad reference, causing the following problem.
For example, assuming that delay in transmission occurs at some midpoint in the video frame and it is sought to recover delay by transmitting data remaining in the final part of the video frame in burst fashion. However, if the delay has already become unrecoverable at the point when burst transfer is started, transmission of one frame cannot be terminated within its video frame time (the time period during which processing must be finished to maintain real-time characteristic), causing a break in image. This problem is apt to occur especially when video data and non-video data are transmitted together.
In the case where the transmission apparatus of the fourth conventional example transmits video data and non-video data together, control is performed so as to transmit non-video data (TCP/IP packet) only when the UDP/IP packet consisting of video data is not transmitted. In the fourth conventional example, a problem arises, for example, in the following case.
For example, assuming that transmission of the TCP/IP packet with very long packet length is started at the time when the UDP/IP packet is not transmitted. In this case, even if a short UDP/IP packet becomes prepared for transmission before transmission of the TCP/IP packet is completed, transmission of the UDP/IP packet cannot be started until termination of transmission of the TCP/IP packet. As a result, transmission of the UDP/IP packet is delayed, thereby to cause a problem of damaging real-time characteristic of the video data.
In an extreme case, when the UDP/IP packet becomes prepared for transmission concurrently with start of transmission of the TCP/IP packet, the UDP/IP packet is in a waiting state throughout the period required to transmit the TCP/IP packet.
Essentially, this problem results from the fact that transmission priority of video data is not enough higher than that of non-video data in the fourth conventional example. As a result, video data may be awaiting transmission according to the circumstances.
Furthermore, the fourth conventional example has the following problem in the case where time-out period is set for the non-video packet (TCP/IP packet) as well.
For example, in the fourth conventional example, when there is a large volume of video data to be transmitted, non-transmission period of video data (UDP/IP packet) is not generated and therefore, transmission of non-video data (TCP/IP packet) is delayed extremely. For that reason, the application that has tried to transmit the TCP/IP packet times out, thereby causing failures in stable system operation.
Essentially, the above-mentioned problem arises from the simple algorithm of transmitting non-video data (TCP/IP packet) only when the UDP/IP packet is not transmitted.